2021年末版Control Tower総まとめ〜これからAWSマルチアカウント管理したい人に向けて〜 #reinvent
こんにちは、臼田です。
みなさん、AWSアカウントの管理してますか?(挨拶
今回はJapan APN Ambassador Advent Calendar 2021の一環で記事を書いています。9日目です。
APN Ambassadorsについては2日目の記事APN Ambassadorsってなんだ?2021年度版を見てください。昨日のエントリーはデロイト トーマツ ウェブサービス(DWS)代表 国本さんの『AWS Well-Architected フレームワーク 勉強会』のススメでした。私も以前Well-Architectedフレームワーク勉強会の記事を書きましたが、この勉強会は皆様の組織のAWSを活用するメンバー全員でぜひやってほしいです。
この記事では今回2021年のre:Inventでもたくさんのアップデートが発表されたマルチアカウント管理のサービスであるAWS Control Towerについて、最新機能も含めたまとめを行いつつ、これからAWSマルチアカウント管理をしていきたい、という方が参考になるように書いていきます。
AWSマルチアカウント管理ってなに?
企業・組織がAWSを利用していくと課題になることの1つがAWSアカウントの管理です。
AWSアカウントはAWS環境を分離する大きな単位であり、現在は1つのAWSアカウントにたくさんのシステムを乗せることはアンチパターンであり、システム単位で分割することはもちろん、1つのシステムに対しても開発・検証・本番といったステージ単位で分割することがベストプラクティスになっています。
最初に1つのシステムのために3つのAWSアカウントを作成しただけであれば、この管理に困ることはありません。しかしAWSの利用が進むと管理すべきAWSアカウントはどんどん増えていきます。これに伴い課題がたくさん出てきます。
バラバラなセキュリティ対策、ずさんなユーザー・アカウント管理、誰も知らないリソース、増え続ける無駄なコスト、分業により低下する俊敏性などなど…。
このような課題に対する根本的なアプローチの1つがAWSマルチアカウント管理を行っていくことです。そしてこれを簡単にかつ強力にサポートしてくれるマネージドサービスがAWS Control Towerです。
Control Towerを利用したマルチアカウント管理のメリット
Control Tower登場以前にもAWSマルチアカウント管理の概念や実際にそれを実現している企業・組織はありました。AWSではこのようなマルチアカウント管理のベストプラクティスに沿った環境をLanding Zoneと呼んでいます。
Landing Zone自体に明確な定義があるわけではありませんが、概ね以下のような機能を持ちます。
- ID管理: 各AWSアカウントを利用するユーザーとアクセス権限の管理
- ガードレール: AWS利用者が反する操作しないように検知・防止
- ベースライン展開: セキュアで統制された環境を自動的に払い出すための仕組み
- ログ管理・監視: 必要なログを集約・可視化し健全な状態を保つ
- 請求管理: 全体のコストを適切に管理・最適化
従来はこれらを実現するために様々なAWSサービスや、それらを管理するスクリプトなどの整備が必要でした。
Control Towerを利用するとこれらが簡単に実現できます。以下のような構成になります。詳細はここで把握しなくてもいいのでざっくり雰囲気を掴むために画像を参照してください。
IDはAWS SSOに集約され、各種ガードレールは目的に合わせて用意されているものを選択して適用でき、アカウント発行すると自動的にベースラインが展開され、ログも1箇所に集約され、請求をまとめつつAWSアカウント単位でしっかり分割できます。
詳細は以下記事でも説明しています。
Control Towerを使う場合の考慮事項
Control Towerも万能なわけではありません。マネージドサービスとして提供されていますので何でもできるわけではないです。以下のような考慮が必要です。
- 料金コストがかかる
- Control Tower自体は無料ですが、ベストプラクティスに基づいたAWSの各種仕組みはもちろん料金が発生します
- コストを極限まで抑えたいならControl Towerの展開するベストプラクティスが適さない場合もあります
- とはいえ特にかかる部分がCloudTrailのログをCloudWatch Logsに出しているところなのでさほどでもないです
- ガードレールに外せない物がある
- ガードレールには必須のガードレールと任意(強く推奨 / 選択的)のガードレールがあります
- ポリシー的に必須のガードレールが許容できない場合にはControl Towerを利用しない選択しか現状ありません
- とはいえLanding Zoneを展開するならどれもほぼ必須です
- 追加のガードレールやセキュリティサービスの展開も必要
- ガードレールとして用意されていないところを独自でSCP設定することは多いです
- GuardDutyやSecurity Hubは別途設定します
- Control Towerでなんでもやってくれるわけではないですが、1からすべてやるよりは楽です
いずれも実践すれば大したことではないですが、夢を見すぎないようにしてください。
以前はもっと制約がありましたが、今回のre:InventでネステッドOUに対応したり、Terraformによるアカウント発行が可能になったりしたのでControl Towerを使うと著しく困る制約は無くなりました。なので私は、これからLanding Zoneを整備したいのであればまずControl Towerを利用する方針で検討しましょうと勧めます。
Control Towerを含めたAWSマルチアカウント管理の設計
設計ではだいたい以下のような項目を検討します。
- ID(認証認可)を何で管理するか
- OU/SCP(追加のガードレール)をどう構成するか
- 追加のセキュリティ機能をどう展開して運用するか
順に詳細に説明します。
ID(認証認可)を何で管理するか
Control TowerではAWS SSOが構築され、ここから各アカウントへアクセスが可能です。
AWS SSOは直接ユーザーディレクトリを持つことができますが、一般的に企業はAWS以外にも様々なサービスで共通的にIDを利用したいため、別のIdPをすでに持っていてこれを利用することが多いと思います。例えばActive DirectoryやAzureAD、OktaやOneLogin等のIDaaSがあります。AWS SSOはこれらと連携が可能なのでそれを検討します。
認証だけではなく認可についても考えていく必要があります。
AzureADであればABAC(属性ベースアクセスコントロール)でアクセス制御が一元的に管理できます。
あとは少しControl Towerとは離れますが権限設計は特に重要です。これはシステム側の要件に強く依存しますので、各システムでIAMに強い担当者を置くか、CCoEなど全体管理のチームからIAM設計の支援に入るべきです。権限周りはセキュリティインシデントに直結しやすいですからしっかりやりましょう。責任の所在を明確にし、教育を行き届かせるポイントです。
OU/SCP(追加のガードレール)をどう構成するか
OUの区切り方はそのままSCPを適用する単位になるので、どのようなガードレールを適用していきたいかを検討しましょう。よくOU単位で使い分けるのは以下のガードレールです。
- Amazon S3 バケットへのパブリック読み取りアクセスが許可されているかどうかを検出する
- Control Tower純正の強く推奨されるガードレールです
- 原則適用すべきですが、S3のデータを公開する環境だけこれを外します
- OUを分けてそもそもS3のデータを公開しない環境は絶対にそれができないようにしたほうがいいです
- 特に重要なデータを扱う環境は、S3に公開データを置くAWSアカウントと分離しましょう
- リージョン制限
- ユーザー追加のSCPにて対応します
- 今回のre:Inventでも利用できるようになりましたが、Landing Zone全体での共通適用しかできないので注意
- ユーザー追加のSCPではリージョン制限の例外ユーザーを調整できることもメリットの1つです
- グローバルにサービスを展開していたり、リージョン跨ぎのDRやバックアップがある環境はこれが比較的緩くなります
- 一方でその要件がなければ、管理が行き届かなくなるので不要なリージョンを制限することはよくあります
OU設計のベストプラクティスは以下の記事でも紹介されています。
本番環境と開発・検証環境はSCPの厳しさが分かれるのでOUを分けることは多いです。あとはアカウント作成時や初期セットアップのためのDeployment OUやポリシー検証用のPolicyStaging OUなどは必須の部類です。
追加のセキュリティ機能をどう展開して運用するか
AWSの強力なセキュリティサービス郡は現状直接Control Towerとは連携しません。それぞれどのように展開するかを検討する必要があります。対象は主に以下です。
- Amazon GuardDuty
- AWS Security Hub
- Amazon Detective
- IAM Access Analyzer
GuardDutyとSecurity HubとIAM Access AnalyzerはAWS Organizationsと連携が可能なので、これを活用することで一括で展開が可能です。管理の委任が可能なので、Auditアカウントに委任するといいでしょう。セキュリティ機能をRootのAWSアカウントで行うべきではありません。
なお、Security HubはOrganizations連携をしても細かい設定ができません。Security Hubのセキュリティ基準の細かい調整やDetectiveの展開などを行うために、Control Towerカスタマイズソリューション(CfCT)を利用するといいです。以下の記事が参考になります。
これらのサービスは有効化するだけではなく運用していく必要があります。Organizations前提ではないですが以下が参考になります。
その他参考情報
- 「AWS Control Towerを利用したマルチアカウント管理とセキュリティ統制」JAWS DAYS 2021登壇資料 #jawsug #jawsdays #jawsdays2021 #jawsdays2021_C | DevelopersIO
- 少し古いけど体系的に説明した資料
- 動画があるのでいろいろコンテキストが補完できると思います
- AWS Control Tower の記事一覧 | DevelopersIO
- 最新情報含め色々あります
- AWS Control Tower とは - AWS Control Tower
- AWS公式ユーザーガイド
- 原本も大事なのでちょくちょく見る
- 特に更新が多いので英語で表示することを推奨
- [レポート] AWS ControlTower環境のカスタマイズとスケーリング #COP401 #reinvent | DevelopersIO
- 最近のControl Towerまとめ公式セッション
- これもよくまとまっています
- AWS環境にセキュアなベースラインを提供するテンプレート「Baseline Environment on AWS」のご紹介 | Amazon Web Services ブログ
- 最近出てきたソリューションのBLEA
- CDKとガードレールを理解するのに役立つコンテンツ
- CDK で AWS のセキュリティベストプラクティスに沿ったベースラインを展開できる Baseline Environment on AWS(BLEA)を触ってみた | DevelopersIOがやってみた記事です
まとめ
re:Invent 2021ではAWS Control Towerが更に強化されてこれまで制約になっていた部分が無くなりました。
これから更に採用する方が増えると思いますのでぜひこれを参考にしてください!